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ABSTRACT 

The National Oceanic and 
Atmospheric Administration's 
(NOAA) National Environmental 
Satellite, Data, and Infor- 
mation Service (NESDIS) is 
responsible for the operation 
of the NOAA geostationary and 
polar orbiting satellites. 
NESDIS provides a wide array of 
operational meteorological and 
oceanographic products and 
services and operates various 
computer and communication 
systems on a 2 4 -hour, seven 
days per week schedule. 

The Anomaly Reporting System 
contains a database of 
anomalous events regarding the 
operations of the Geostationary 
Operational Environmental 
Satellite (GOES) , com- 
munication, or computer systems 
that have degraded or caused 
the loss of GOES imagery. Data 
is currently entered manually 
via an automated query user 
interface. There are 21 pos- 
sible symptoms (e.g. , No Data) , 
and 73 possible causes (e.g., 
Sectorizer - World Weather 
Building) of an anomalous 
event. The determination of an 
event's cause (s) is made by the 
on-duty computer operator, who 
enters the event in a paper- 
based daily log, and by the 
analyst entering the data into 
the reporting system. The 
determination of the event's 
cause (s) impacts both the 
operational status of these 
systems, and the performance 
evaluation of the on-site 


computer and communication 
operations contractor. 

The Anomaly Reporting Expert 
Assistant System (AREAS) is an 
interactive, rule-based 
demonstration prototype using 
backward chaining goal-directed 
inference. Upon input of a new 
event's symptom, AREAS queries 
a database of prior events with 
associated symptoms and causes, 
and then suggests possible 
causes to the analyst. AREAS 
reasons with the archived 
events, a rule-based repre- 
sentation of the satellite, 
communication, and computer 
subsystem's physical relation- 
ships, heuristics acquired from 
resident domain experts, and a 
mean best fit of prior events 
with the new event. Whether the 
analyst confirms AREAS' sug- 
gested cause or enters a new 
one, the event, with its 
related attributes, is entered 
into the database and thus 
provides an up-to-date 
environment in which AREAS can 
operate. AREAS includes a help 
system designed to assist new 
users and it provides technical 
information, with graphical 
representation, on the GOES, 
communication and computer 
subsystems . 

Key Words: Knowledge-Based 
System, Rule-Based, Backward 
Chaining, Goa 1 -D ir ected 
Inference, Environmental 
Satellite Systems, Anomalous 
Event Diagnosis, Intelligent 
Database 
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INTRODUCTION 


The National Environmental 
Satellite, Data, and Infor- 
mation Service (NESDIS) 
oversees the operation of 
civilian satellite systems used 
for Earth-observation, and the 
creation and maintenance of 
global databases in the 
physical and life sciences. 
NESDIS provides products and 
services derived from 
environmental data that are 
applied to the protection of 
people and property, national 
economic systems, and the 
development and distribution of 
food, energy and other natural 
resources on a national and 
international level. 



Figure 1 - GOES East in Orbit 


NESDIS is responsible for the 
operation and maintenance of 
the Geostationary Operational 
Environmental Satellite (GOES) , 
located at 112° West as shown 
in Figure 1 above , and the GOES 
Data Distribution System 
(GDDS) . It is staffed with 
experienced meteorologists, 
oceanographers, computer 
specialists, and administrative 
personnel, as well as employees 
new to the environmental 
satellite domain. A contractor, 
PRC, Inc., provides com- 
munications and computer 


operations support for the 
GDDS. 


Why Artificial Intelligence? 


NESDIS determined to evaluate 
the potential of Artificial 
Intelligence (AI) tools and 
techniques in response to the 
challenge of sensing, 
communicating, processing 
analyzing and 
ever-increasing 
environmental 
products. This increase is due 
to the larger number of ground- 
based data collection systems, 
satellites in orbit with 


distributing 
volumes of 
data and 


improved 


sensors 


and 


additional data shared by other 
organizations, both public and 
private, in the United States 
and foreign nations. 


OBJECTIVES 


Four ob j ect i ves were 
established for the development 
and demonstration of the 

Anomaly Reporting Expert 
Assistant System (AREAS) 
prototype . They were : 

1. Develop a help system for 
anomaly reporting. 

2. Increase personal knowledge 
of GDDS. 

3. Retain valuable GDDS exper- 
tise. 

4. Demonstrate the ability of 
AI to improve administrative 
and operational tasks. 

CURRENT ANOMALY REPORTING 
SYSTEM 


As a result of a computer 
generated error message or 
other indicator, a computer 
operator documents the problem 
in the paper-based Envi- 
ronmental Satellite 
Distribution/Interactive 
Processing Center (ESD/IPC) 
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Daily Log. At the conclusion of 
a shift, the shift supervisor 
synopsizes the Daily Log 
entries into multiple summary 
reports including the 
Operational Problem report. A 
combined hardcopy daily report, 
including the Daily Log and 
Operational Problem report, 
among others, is then distri- 
buted to management and staff. 
Each morning, contractor and 
NESDIS personnel meet for a 
short discussion of the most 
critical issues encountered in 
the previous 24 hours. On a 
daily basis a NESDIS staff 
member evaluates the Daily Log 
and Operational Problem report 
and enters appropriate 
information into the Anomaly 
Reporting System (ARS) . The 
staff shares this task on a 
weekly, rotating basis. 

The ARS queries the user for 
the following information: 

Julian Date 
Satellite 
Zulu Time 
Symptom ( s ) 

Number Products Affected 
Probable Cause (s) 

Responsible Division 
Number Expected 
Number Actuals 
Number External Lost 

The 21 possible symptoms and 73 
possible causes are available 
to the staff in hardcopy or in 
an on-line text file. For 
example : 

SYMPTOM CODES 


CODE # ENTRY 
01 DATA EARLY 

14 NO DATA 

21 WRONG DATA 


CAUSE CODES 


CODE # ENTRY 

01 AIR COND/HEATING 

53 SECTOR I ZER-WWB 

73 VIRGS 


Accompanying the hardcopy 
symptom and cause list is a 
GDDS Diagram, part of which is 
shown in Figure 2 . This diagram 
is not available on-line in the 
ARS. 

The complete diagram (not shown 
here) outlines the flow and 
processing of data for the 
major communications and 
computer systems from the GOES 
spacecraft to NOAA's facilities 
at Wallops Island, Virginia, 
and Suitland and Camp Springs, 
Maryland. With this 
information, along with other 
available documents, assigned 
staff must evaluate the Daily 
Log and Operational Problem 
report and determine the cause 
of the anomalous event. After 
determination of the problem's 
cause and input of the data, a 
daily report is produced for 
dissemination . 

ANOMALY REPORTING EXPERT 
ASSISTANT SYSTEM 

1.0 Problem Identification 

A loss of expertise was 
recently suffered due to the 
retirement and promotion of 
several employees. New emp- 
loyees needed access to the 
lost expertise in order to 
accurately determine the cause 
of anomalous events and prevent 
future occurrences, if 
possible. The current ARS has 
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WORLD WEATHER BUILDING 

(CAMP SPRINGS, MARYLAND) TO microwave 

AT SUITLANP 



Figure 2 - GDDS Diagram: WWB 


no help system and several of 
the new employees have limited 
knowledge of the GDDS. 

2.0 Knowledge Acquisition 

Domain knowledge was acquired 
through interviews with domain 
experts, one of whom has since 
retired. Extensive GDDS docu- 
mentation, including the GDDS 
Operations and Maintenance 
Contract , was reviewed. In 
addition, the current Anomaly 
Reporting System, ESD/IPC Daily 
Logs and Operational Problem 
reports. Daily and Weekly ARS 
reports were also analyzed. 

3.0 Analysis and Design 

The analysis and selection of 
knowledge representation and 
the development tool along with 
the system design have been 


integrated within a single 
category. The intent is to 
emphasize the real world 
environment in which all three 
issues are frequently 
considered concurrently, 
especially during initial 
prototyping. 

3.1 Knowledge Representation 

Evaluation of the existing data 
indicated that an attribute/ 
value representation scheme 
combined with rule-based 
processing would be sufficient 
for initial prototype 
development. Since the current 
ARS uses a query/ response 
interface it was decided to use 
backward chaining, goal 
directed inference to emulate 
the existing process. 
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3.2 Tool Selection 


4 . 0 Prototyping 


The criteria for tool 
selection, in addition to those 
identified above, were low 
cost, a simple development 
environment , and a short 
learning curve. The tool 
selected was Level5 Expert 
System Software (DOS Version 
1.3) by Information Builders, 
Inc. This expert system shell 
fit the identified small system 
prototype requirements: a 
default query / response 
interface, symbolic represen- 
tation used in an if/then rule- 
base environment, and the need 
to perform simple calculations. 

3.3 System Design 

The system design stressed 
modularity for ease of 
development, explanation, use, 
and maintenance. The shell's 
default user interface was 
employed for the selection of 
menu items and the input of 
numeric data. Individual 
knowledge base modules were 
used for each of the primary 
data items required for 
inferencing. The help system's 
customized graphic and 
narrative explanation screens 
were integrated through 
Level5's explanation function 
and separate knowledge base 
modules. The help system 
focused on the three major 
components of the GDDS: the 
satellite, data communications, 
and computer processing 
subsystems. A simple mean 
statistical analysis was 
provided through symptom 
specific knowledge base 
modules. This architecture is 
demonstrated in Figure 3 . , 
below. 


Modularity was a key issue 
during the rapid prototyping of 
AREAS since the knowledge 
engineering process was being 
used as a learning tool for the 
GDDS environment. A large 
number of small, easily 
modified knowledge bases were 
initially prototyped to 
establish the relationship 
among various data elements, 
particularly between symptoms 
and causes, and to model the 
physical subsystems. 

4 . 1 Knowledge Sources 

4.1.1 Heuristic Knowledge 

Heuristic knowledge was 
obtained from the domain 
experts through their 
explanation of Daily Log and 
Operational Problem report 
entries and GDDS processing. 
For example, the hardware 
element designation "RTIR" 
(i.e., RealTime InfraRed) is 
not specified in the sectorizer 
subsystem node of the Wallops 
version of the GDDS Diagram, 
but it was identified by one of 
the domain experts as important 
in distinguishing between 
sectorizers at the World 
Weather Building (WWB) and 
those at Wallops Island. This 
knowledge was then incorporated 
into the rule base of AREAS. 

4.1.2 Documentation 

A number of different documents 
were used as primary knowledge 
sources. NESDIS Programs - NOAA 
Satellite Operations identified 
the organization's mission and 
major systems used in carrying 
out that mission. The GDDS 
Operations and Maintenance 
Contract was indispensable in 
identifying subsystems and 
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Figure 3 - AREAS Architecture 


their constituent components. A 
memorandum to all the 
organizations responsible for 
the GDDS operation explained 
the use of ARS as, in part, an 
instructional tool. It included 
the GDDS Diagram, of which the 
WWB segment at Camp Springs, 
Maryland is shown in Figure 2 , 
and the lists of possible 
symptoms and causes. The 
memorandum's express purpose 
was to establish a common 
framework in which to identify 
and respond to anomalous 
events . 

4.1.3 ARS Database 

Evaluation of the ARS data base 
provided input to the data type 
classifications used in AREAS, 
as provided by the expert 
system shell: numeric, 
attribute/value, and string. 


4.2 Process of Discovery 

Since one of the objectives of 
building AREAS was to gain 
additional insights into GDDS, 
AREAS had to be able to 
represent GDDS physical 

relationships among its 
subsystems and components. For 
example, the following 
"identify symptom" rule 

represents the interpretation 
of, and the relationship 
between, the shift supervisor's 
comment in the remarks column 
of the Operational Problem Log 
and the identified symptom. 

RULE identify symptom 

IF remark IS Short-SZ Halted in RCV 

THEN symptom identified 

AND symptom IS Degraded Data 

The remark, "Short - SZ Halted 
in RCV," means the sector izer's 
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processing of the imagery 
product's data set during 
transmission was terminated 
while in receive mode. The 
symptom is thus classified as 
degraded data ( i . e . , by 
definition 50 percent or more 
of the complete image was 
produced and was of animation 
quality) . The next rule, 
"identify responsible 
organization," establishes the 
relationship between the 
identification of the satellite 
and a specific sector izer and 
the organization responsible 
for its operation. 


RULE identify responsible 
organization 
IF symptom identified 
AND satellite IS GOES East 
AND hardware element IS Sectorizer 
6A11 

THEN responsible division 
identified 

AND responsible division IS SSD 


4.3 Help System 

The help system provides query 
specific information in 
narrative and graphical formats 
of crucial areas of the GDDS. 
If the user doesn't understand 
a particular query, such as 
"What was the responsible 
division?" a help screen is 
available with additional 
information explaining the 
physical system relationships 
and the organizations 
responsible for their 
oversight. Mutually supportive 
information from different 
documents is merged as well in 
help screens. For example, a 
glossary of terms such as the 
one shown below was merged with 
the GDDS Diagram in Figure 2, 
above . 


COMM RACK 

Communications Rack 

DCS 

Data Collection System 

IFF A 

Interactive Flash 
Flood Analyzer 

O & A 

Orbit and Attitude 

SEXRS 

Sec torizers 

SOCC 

Satellite Operations 
Control Center 

TELCO 

Telephone Data Lines 

VAS 

VISSR Atmospheric 
Sounder 

VDUC 

VAS Data Utilization 
Center 

VIE 

VAS Interface 
Electronics 

VIRGS 

VISSR Image 

Registration and 
Gridding System 

VISSR 

Visible and Infrared 
Spin - Scan 
Radiometer 

XBAR 

Crossbar Switch 


4.4 Statistical Analysis 

The initial objective of a 
statistical analysis of the ARS 
data base was to provide the 
user with background 
information as to the apparent 
relationships between symptoms 
and causes. This was accomp- 
lished through a simple mean 
analysis of the type and number 
of causes attributed to each 
symptom. This analysis, coupled 
with the rule output reviewed 
above, produces a diagnosis as 
shown below in Figure 4. The 
user is then at liberty to 
accept or reject the diagnosis. 

4.5 Introduction of Knowledge- 
Based Systems 

The focus on simplicity of the 
prototype's development, 
architecture, purpose, and 
operation was important. These 
issues had to be easily 
explainable to use AREAS as an 
introduction of knowledge 
engineering concepts. A basic 
approach was taken in knowledge 
acquisition, representation, 
search, and inference for this 
purpose. 
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Based on the following information: 

Julian Date: 

310 

Satellite: 

GOES East 

Zulu Time: 

0200 

Symptom: 

No Data 

Number of Products Affected: 

1 

Hardware Element: 

SZ6A11 

Do you agree with the diagnosis below? 

Probable Cause: 

Sectorizer-WWB 

Responsible Division: 

<=> Yes 
No 

SSD 


Figure 4 - Diagnosis Screen 


5.0 Verification and Validation 

Verification was performed 
through analysis of shell- 
produced knowledge trees 
linking all the goals, rules 
and attributes in a given 
knowledge base in a logical 
order of precedence starting 
with the top-level goal. Each 
logical path through a 
knowledge base was also 
manually derived and tested. 

Initial validation was 
performed by comparing archived 
results of domain experts' 
analyses to system generated 
conclusions. Subsequent 
validation was conducted by 
domain experts through the 
evaluation of results from test 
data sets processed by AREAS. 


6.0 Test and Evaluation 

The qualitative test and 
evaluation of the AREAS 
demonstration pr ototype focused 
on its potential use as a help 
system in identifying the 
symptoms and causes of 
anomalous events. Feedback from 
user surveys indicated: 

- a positive reaction to the 
display of statistical data but 
a need to further highlight 
only the most prevalent 
symptom/cause ratios; 

a desire to have AREAS 
identify individual GDDS 
components and their output of 
specific products (i.e., 
products are currently assigned 
identification codes and are 
logically linked to specific 
hardware elements within GDDS) ; 
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- approval of the graphics used 
but a request for more detail 
in representing GDDS subsystems 
and components ; 

- the need to allow multiple 
symptom identifications for a 
single anomalous event (e.g., 
the symptoms Data Incomplete 
and Degraded Data can be 
specified for a single event in 
the current ARS) , and the 
ability to generate multiple 
symptom/ cause records per 
report; and 

- support for the ability to 
easily review input prior to 
data base update and subsequent 
report generation. 

CONCLUSION 

Part, but not all, of each 
objective was accomplished in 
the development and 
demonstration of AREAS: 

1. Develop a help system for 
anomaly reporting. 

The current ARS has no help 
feature. One of the expressed 
purposes for users and new 
employees using the ARS is to 
train them in the nomenclature 
and processes of the GDDS. One 
of the primary objectives of 
AREAS was the linkage of 
relevant narrative and 
graphical information to 
specific user queries. Based on 
user feedback AREAS has made an 
important step in identifying 
user needs in the successful 
analysis of anomalous events in 
GDDS. 

2. Increase personal knowledge 
of GDDS. 

The author is a novice with 
satellite-based systems but 
experienced in knowledge-based 


systems development . Through 
the development of AREAS and 
preparation of this paper, he 
was able to take advantage of 
the process of discovery 
highlighted by the knowledge 
engineering process to gain a 
better understanding of the 
GDDS. 

3. Retain valuable GDDS exper- 
tise. 

The retirement and promotion of 
several employees who were very 
experienced in the GDDS created 
a potential problem for new 
employees assigned to anomalous 
event tracking and analysis. 
Part of their expertise, 
through the knowledge 
engineering process, was 
captured for use through AREAS. 

4. Demonstrate the ability of 
AI to improve administrative 
and operational tasks. 

The only automated tool 
available within ARS to search 
the database requires the user 
to possess a clear idea of what 
is being searched for and 
familiarity with the data types 
and structures employed. The 
purpose in providing the user 
with a simple mean analysis of 
the data represents the initial 
step in providing ready access 
to analytical tools and 
results. These tools, when 
augmented by heuristic rules to 
constrain the search space, 
provide a reasonable method of 
diagnosis to assist the user in 
making decisions. In the future 
these results may identify 
potential trends in specific 
GDDS subsystems and hardware 
elements, as well as processing 
methodologies . 

AREAS, with its focus on 
simplicity, provides the 
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opportunity to introduce 
knowledge-based systems 
concepts, development and use 
to employees in a direct, 
hands-on way. It highlights the 
value of knowledge engineering 
as a process of discovery. It 
also demonstrates the ability 
to harness the knowledge of 
disparate sources of 
information and provides a 
focus for that knowledge on 
problem-solving in the domain 
of anomalous event diagnosis 
for environmental satellite 
systems . 
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